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(54) Signaling For Parameterized Quality of Service (QoS) Support 



(57) The creation, modification, and deletion of a 
traffic stream (224) with parameterized QoS expecta- 
tions between two communicating stations (205 and 
207), when there is no built-in mechanism for support of 
parameterized QoS expectations, requires signaling of 
traffic characteristics and QoS parameters between the 
management entities such as SME (212) and MLME 
(21 4) and between the MAC entities of the communicat- 



ing stations (205 and 207). Either the station (205 and 
207) or a hybrid coordinator may initiate the signaling. 
The end result of the signaling is the creation of a new 
traffic stream that is used to associate user traffic to a 
particular set of traffic characteristics and QoS param- 
eters, which are then used In the scheduling of the trans- 
mission of the user traffic. Another end result of the sig- 
naling is the modification of an existing traffic stream in 
terms of its traffic characteristics and QoS parameters. 
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Description 

FIELD OF THE INVENTION 

to «°HLt«?'' 7^''''''" ^^''^'^"^ networking, and particularly to providing quality of service (QoS) 

traffic tra^^^^^^^^^ communications network through the specification and exchange of Qoi parameters for network 

BACKGROUND OF THE INVENTION 

[0002] Communications networks use a transmission medium to transmit Information In the form of computer data 
voice music, video, etc from one station to another. The communications medium may be a wired link, a fiber optic 

TrrZLTrH^^ I? I ""''^'f ' ""^y ^^^'^ frequency, infrared, laser light, and 

rmt!^^r w tl^^^ ^ combination of different types of communications links. 

^t^unl r^'VT ^'f °' ^ dedicated communications links between each 

TnfnZT '"^TT" "'^ ^ ''^'^^ transmission medium to carry the transmitted information. Examples 

Of .nfomiat.on networks using a shared transmission medium include: Ethemet, token ring, wireless Ethemet (IEEE 
802.11), and many proprietary networks. 

wh^n 1.^°*^"^'' ^ communications medium between multiple stations, there are situations that arise 

S^tinn. f ^^Z^'^^'^^'^, »° « significant amount of time before they are able to transmit their data. Additionally, 
r^^t nL cT transmissions from different stations occur and result In the mutual destruction o 

he transmissions. Such situations are undesirable in providing quality of sen^lce (QoS) to multimedia, voice, and data 
transfers and in making efficient use of scarce spectrum on a wireless medium 

[0005] For some applications, such as voice telephony, video teleconferencing, and other real-time, bi-directional 

tTJt^Z'rS'^T"' TTf "■""'^^ "^"^^^'^ ^"^ ^^P'^'y '^^S^^^^ '^"^ perfomiance of the applications 

InH in th ^f^^P^^^'^- ^''^^P'e. in voice telephony applications, if the delay between one us^ speaking 

LttZion 7'^^ ' 1"'? 1" ^'f^'^'"'^" « '^"^ milliseconds, the delay becomes noticeable to the users and the useri 
satisfaction level for the telephone connection begins to drop 

[0006] One way to ensure that applications requiring a low maximum networi< latency receive the level of service 
that they require is to implement some form of QoS transfers of data traffic between stations. In many networks with 
2f DrioSJ^td wr.T"'T'°"' ^ partitioned into multiple categories and streams. The categories 

c^LacJiti F^r ^TTV'^ parameterized according to their specific performance requirements and traffic 
than^riffi. ^Tf ' T"" ''^"^"'^ ^ ^^'^''''^"^ conversation between two users will be given a higher priority 

«^an traffic carrying data for a file transfer between two computers; whereas traffic carrying a tdeconferencing video 

flZT^n parameterizing streams for the traffic, traffic of higher priority or higher QoS demands 

recejves better service, and hence these networks offer and meet performance guarantees 

on?v?«vlT«t^r\''^""'K'1*^°"^^' '"'P'«'"«"t^d a" IEEE 802.11e wireless communications network, provide 
only a fixed (static) pnonty for messages in the differing categories. All messages of a given traffic category share a 
sing e pnonty level. Given a fixed number of different traffic categories, it may not be possible to provide the neJessa-^ 

L'n'd al''r'"t°" 'TT "'"^ °f diffeLtiation between rSess^Isl^qu^ 

and a fixed pnonty method, such as traffte categories, does not provide the needed flexibility to specify different com 
munications parameters on a message-by-message basis. Additionally, the ability to change, on the fly a messaae's 
moor? K '"^ requirements change can greatty enhance the netw'ork-s perioSianTe ' 

ametersl"rl.« f 1°' ^ "^^^^°^o'°9y ^^^at pemilts the specification of various communications pa- 

rameters on a message-by-message basis and the exchange and negotiation of the communications parameters be- 
tween communicating stations as dictated by performance needs and bandwidth availability. 

SUMMARY OF THE INVENTION 

n?r«^' . ^ '"'t'««"9 a QoS action on a traffic stream with 

elm. "r °f f ''P^^'^"^"^ ^ «rst communications station In a communications network, wherein the first 
co^trrM^S"' K '^°'"P"^'"9 « higher layersignaling unrt. a station management entity (SME), a medium access 
Taver 1 PHY Lv.rT'' ^T"" " P'^^''"' '^^^^ management entity (PLME), a MAC sub- 

X:^MpLrf' . TT '^°'"P"^'"9 t'^^ ^'^P^- -«"dlng a QoS action signal from the higher layer signaling unit 
to the SME of the first station, creating a first QoS action primitive, the first QoS action primitive comprising a first QoS 
act on frame body, at the SME of the first station and issuing the first QoS action primitive to the MLmI of tTe fiJt 
station, transmitting the first QoS action frame to a second station, receiving an aLowledgment frorthe sioS 
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station, creating a second QoS action primitive at the MAC sublayer of the first station, and issuing the second QoS 
action primitive to the SME of the first station. 

[0010] The present Invention provides a number of advantages. For example, use of a preferred embodiment of the 
present invention allows the specification of different communications parameters based on the needs of the Individual 

5 messages. This allows for each individual message to have a different set of parameters, providing the network with 
a high degree of flexibility to meet differing QoS expectations and controllability to transfer user traffic based on the 
overall demands. 

[0011] Also, use of a preferred embodiment of the present invention allows the exchange and negotiation of QoS 
parameters for traffic streams, allowing the network to meet various performance requirements and traffic conditions. 
10 [0012] Additionally, use of a preferred embodiment of the present invention permits the renegotiation of QoS param- 
eters after an initial assignment of QoS parameters should the assigned QoS parameters not meet (or exceed) the 
needs or expectations of the communicating parties. 



15 



BRIEF DESCRIPTION OF THE DRAWINGS 

[001 3] The above features of the present invention will be more cleariy understood from consideration of the following 
descriptions In connection with accompanying drawings In which: 

Figure 1 illustrates a prior art diagram of a typical wireless local area network adherent to the IEEE 802.11 technical 
^0 standard; 

Figures 2a and 2b illustrate the creation, modification, or deletion of traffic streams among communicating stations 
according to a preferred embodiment of the present Invention; 

Figures 3a-h Illustrate the structure of various QoS action frame bodies and primitive parameters according to a 

preferred embodiment of the present Invention; 
^5 Figures 4a-e illustrate the structure of action frame bodies (for both request and response) for adding, modifying, 

and deleting traffic streams according to a preferred embodiment of the present invention; 

Figures 5a and 5b Illustrate the exchange of QoS action primitives and action frames in the creation, modification, 

or deletion of traffic streams between management entities or communicating stations according to a preferred 

embodiment of the present Invention; 
30 Figures 6a-b illustrate the structure of a traffic specification element used to specify traffic characteristics and QoS 

parameters for a traffic stream according to a preferred embodiment of the present Invention; 

Figure 7 Illustrates the structure of a traffic classification element used for associating data units to their traffic 

streams according to a preferred embodiment of the present Invention; 

Figures 8a-c Illustrate exemplary sequences of QoS action primitives and action frames in the addition, modifica- 
35 Won, and deletion of traffic streams between management or MAC entitles In communicating stations according to 

a preferred embodiment of the present Invention; and 

Figure 9 illustrates exemplary uses of traffic streams according to a preferred embodiment of the present invention. 



40 



DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS 



[0014] The making and use of the various embodiments are discussed below In detail. However, it should be appre- 
ciated that the present Invention provides many applicable Inventive concepts, which can be embodied in a wide variety 
of specific contexts. The specific embodiments discussed are merely illustrative of specific ways to make and use the 
invention, and do not limit the scope of the Invention. 

45 [0015] Sharing a communications medium Is a necessity for a majority of the communications networks (networks) 
available today. Only in a small number of networks are there enough resources to permit dedicating communications 
media between pairs of users (or stations). For most purposes, dedicating a connection between pairs of users is an 
inefficient use of bandwidth resources. Sharing a communications medium between multiple users allows for more 
efficient use of the medium, because when one user may be idle, another user may have data to transmit. Sharing is 

so also more cost efficient because a smaller amount of the media is needed to support the information network. Note 
that this Is also true for wireless, over-the-air networi<s, where if sharing were not used, then more "air", i.e., spectrum, 
must be dedicated to supporting the network. 

[0016] However, sharing a communications medium between multiple stations means that in certain circumstances, 
more than one station could desire access to the medium at the same time or a station may desire access when the 
55 medium is already busy. This is known as contention and contention leads to collision and waiting. Because only one 
station should have access to the communications medium at any given time, the other stations with data to transmit 
should wait until the first station is either finished transmitting or Its allotted time is expired. However, since the stations 
do not have other channels over which they can coordinate their transmission times other than the channel they use 
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loai7] Long delays lead to communications with larae latenciec: Thoro or^ «^o« 

nroU°;^S^^^ quantitative .ay. ,n a qualitative wa, user traffic Ir, the 

latency requirements are asslgned S^Prio^^^^^^^^^^^^ 
latency requirements, and hence the hiqhe rSrU tr^ff^^^^^^^^ 

priorities are sometimes required to wafan ZZTlZTT. '^'""''^ "^^^"'^ '^'^-^ 

extended wait-times are «.«lon.H " „ ™" T''""' °^ aPP'ications that are not sensitive to 

While applications such as vole a^d vZt sS^^^^^ 

in the network is parameterized into traffic streamnnd t!ntft!rl^^ ''^^ ^ qi^antitatlve way. user traffic 

In the corresponding traffic speciS?n7si?h SoS n Jl *° parameters defined 

required for the data transfer of he t X Tea^leT^^^fZT''- ^T'^ ""'"^ """"^^^ 
as voice may have lower data rate bu^r deT^^^ ^''^"^P'"' applications such 

[001 9] The discussion below J foc..V^H «n 7 ^ f parameter values than applications such as video. 

lions Jetworks adhSent to an ,EEE 8oa 1 1 e fericT^r^'r'"" ' "'^^'^^ 

other communications networks, both wi e^ ^d Se' J^^^^^^^^^^^^ P^^"' '"^^^ " "PP"''^''''''^ '° 

expectations. Examples of such networks include but«r! n Vr f ^ ^ ^"PP*"^ parameterized QoS 

[0020] Referring now to Figurri ^SLaram foJ^ of T ^^P"'"'^"' ^omeRF, etc. 

according to the IEEE 802.1 I^ Ss tech^SfsTa?^^^^^^ ("^^^ '-»-"-tion 

- Telecommunications and Infonriation exSranrb!w.^ ^''^ Infomiation technology 

^5 requirements - Part 1 1 • WiretesriAN MpI .^f T ' ^""^ "^^t^Po'^n area networks - Specffic 

is incorporated here n br^encrA draft TulTr. ^t"':^ '"^^^ ^^^^^ Specifications." which 

StandardforTelecommunicmionsandinfol^^^^^^^^^ 

1 1 - Wireless Medium Access Contr^' M°AC)t J Z^^ZTphZo::^- ' ^^^^.r.^'^'^''^ requirements - Part 
Enhancements for Quality of Service (QoS) lEFF nn^ i /no I ^ m ^ specifications: Medium Access Control (MAC) 

in direct communications. A BSsts staie^ ?olId and r^S "Th "'""'^^ P^^-P^^^ 

to AP 130 and BSS 120corresponrtoJMloTn A? a stat on fhl^ access point (AP). BSS 110 corresponds 
A DS allows multiple BSSs to fnterconn^ect wifh on^ t^ll T ^°""^cted to a distribution system (DS) 1 50. 
used in a DS may be the samHs the Sdtm used i^^^^^ extended sen,ice set (ESS) 1 60. The milium 

BSSs may be wireless radio frequencvTS whSe « nVl. ''^^ ^^^^ 

Wireless station (STA) 170 whi.Xern'alTolss 2 is anTp Uo'fnTat^ iToTbss 110 is an AP 130 and a 
SoSr AsV "'^'7" °' '° is tpic^l t^day), bin S Cave onTIp"'"" 

!:o'in:rBss;;o?o"D^^^ 

addressed (ike any other wirVess station ""^'^ « sl^t'on and can be 
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40 



[0023] stations within a BSS, for example, stations 130 and 1 70 in rc;<; 
without interfering with stations in other BSSs Howrir thf f . ' ""^^ communicate with one another 

« evertheywish;theymustfollowane«ise^^^^^^^^^ 

[0024] A user may be thought of as a statSi o l^Zll^tT """""'^^ maximize perfomiance. 

are using other stations to communrca.e therefore in^l^^^^ ^'1.^"°" '° communicate with other users who 
Will be used interchangeably without its If rnToration ^"^ "^^-^ 

- E ol^^nd cor^S tllfSl^sm^^^^ 'b:rweTnTort"' '"T ^^^^-^"^-^ ^'^^ - -"«<^ 

data untts (MPDU). while manag^r^rtSlc! ^nsr^iSd tt^ZT f ""^""^^ f^'^^) P^^*^'^' 

data units (MMPDU). A unft ma? be fragmented SltTtoottTt^^^^^^ "^"'^ """^^aement protocol 

fragmented into multiple MAC frames ^ ^ ^'"^'^ '^'^^ "'a'"® ^^'^refore may be 
[0026] Timing is a crucial aspect of an IEEE 802 11 wireless lam 

55 types of communications. Other spans of time/r^T.cIml!, ^""^ *° P''^^®"* °r certain 
time spans are SIFS. PIFS. and ?J?rA ^FS fs a^^^^^^ 

the LAN. A PIFS is a point coord^aTng funcToi^^fpSnnrfr^^ '^P'^^''^ "'^"^^^ «P«" 
tl.e.AO.FS.adlstnbutedcoordinatinV=^^^^^^^^ 
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time. A slot time is the maximum amount of time for a station to sense a frame, due to signal processing delay and 
propagation delay that is transmitted from any other station within a BSS. 

[0027] By segregating messages Into different traffic categories, each with a different priority, it is possible to give 
preferential treatment to traffic categories that require preferential treatment to meet QoS expectations. However, there 
are instances when fixed priorities provided by traffic categories are not sufficient to meet the QoS expectations. For 
example, there are times when there are multiple messages in a same traffic category where one message requires 
more bandwidth than another or It needs a lower delay bound, etc. To meet these different needs, a method that permits 
specification of QoS parameters for individual messages is needed. An example of such a situation is when there are 
simultaneously two connections present in the network, with the first connection being a voice only conversation be- 
tween two users and the second connection being a videoconference between two users. It should be readily evident 
that both connections require low latency, but while the voice connection requires a relatively small bandwidth, the 
videoconference requires a significantly greater bandwidth. 

[0028] Additionally, the static nature of traffic categories does not present well when network conditions change or 
QoS expectations change. For example, in a lightly loaded network, an improperly prioritized communications link may 
be able to meet the QoS expectations, but should the network become heavily loaded, the same priority may not be 
able to provide the required performance. Therefore, a dynamic method to assign QoS expectations that allows ad- 
aptation to the values of the QoS parameters Is needed. 

[0029] Therefore, traffic categories are inadequate when It comes to providing parameterized QoS. Traffic categories 
may be thought of as groups of MAC service data units (MSDU) thai are to be delivered through the use of a prioritized 
QoS, whose priority is indicated by its own traffic category identifier (TCID) via a predefined priority mapping. A new 
construct, traffic streams, on the other hand, pemiits either uni- or bi-directicnfl' streams of MSDUs that are subject to 
QoS parameters provided by higher layer signaling mechanisms. The parameterized QoS are indicated by its tramc 
stream's identifier (TSID) and are assigned to the traffic stream via QoS management actions. 

[0030] Traffic streams are added, modified, and deleted through the use of QoS action primitives issued by a station 
management entity (SME) and QoS action frames contained therein. The QoS action primitives are issued by either 
the source or the destination station of the traffic stream. The QoS action primitives may be issued also by a hybrid 
coordinator (HC) serving the source and destination stations of the traffic stream. The SME may be thought of as a 
layer-independent entity and is responsible for functions such as gathering layer-dependent status from higher layer 
entities capable of QoS signaling and from other layer management entities such as the MAC sublayer management 
entity (MLME) and the PHY layer management entity (PLME) and then processing the values of the layer-specific 
parameters. The SME would perform such functions on the behalf of general management entities and implement 
standard management protocols. The MLME and PLME, on the other hand, provide layer-dependent management 
services and functions for the MAC and PHY, respectively.. 

[0031] Traffic streams permit either unidirectional or bi-directional transfer of MSDUs between communicating sta- 
tions with a parameterized QoS. Bi-directional traffic streams may be visualized as two unidirectional traffic streams 
with the source and destination communicating stations reversed but with the same traffic characteristics and QoS 
parameter values. The communicating stations may be a wireless station (WSTA) and a hybrid coordinator (HC), two 
WSTAs, or a WSTA or an HC and a multicast or broadcast group of stations. 

[0032] Referring now to Figure 2a, a diagram illustrates the creation, modification, or deletion of a traffic stream 
between two communicating stations according to a preferred embodiment of the present invention. A communicating 
station 205. which in this example is an HC, is shown communicating to a second station 207, which Is a WSTA in this 
example. Both stations are displayed partitioned into their functional units. However, in general, a communicating 
station that initiates signaling for adding, modifying, or deleting a traffic stream may be either an HC or a WSTA. A 
generic temn used to mean both an HC and a WSTA is a QoS station (QSTA). The HC 205 comprising a higher layer 
signaling unit 210, a station management entity (SME) 212, a IVIAC sublayer management entity (MLME) 214, a MAC 
sublayer 21 6, a PHY layer management entity (PLME) 218, and a PHY layer 220. 

[0033] The higher layer signaling unit 21 0, lying above the MAC sublayer, signals the arrival of a new traffic stream, 
change of an existing traffic stream, or deletion of an existing traffic stream through the use of predefined signaling 
parameters. The higher layer signaling unit 210 may be a signaling mechanism (such as a button on a remote control 
or lifting a telephone receiver off-hook) or a signaling protocol (such as tip and ring signaling used in existing telephone 
networks), for example. 

[0034] According to the IEEE 802.1 1 -1 999 technical specifications, the actual transmission of the data occurs without 
knowledge of any specially assigned priorities and/or QoS expectations. However, in order to meet QoS expectations, 
the MAC entity at the HC needs to know the QoS expectations of the traffic streams existing within the BSS containing 
that HC in order to allocate appropriate channel bandwidth at appropriate times for the data transfer of those traffic 
streams in accordance with the QoS expectations. The MAC entities at the source of the traffic streams also need to 
know the QoS expectations so that the data from different traffic streams sourced within the same station are transmitted 
In appropriate order using appropriate channel bandwidth in line with the QoS expectations. With the fixed priorities of 



5 



BNSDOCID: <EP 1309139A1J_> 



EP1 309 139 A1 



10 



15 



activities for the MAC 216 and the PHY J20 In » ' ?■ ^ ^"^ ^''^ '^'''^^ P'^^'^"® management 

WSTA to the other WSTA is actua^v of Sm^ H n J ^'^"^""^ '"^ssages 262, transmitted from one 

action frames to the HC 257 over 2 S^hi c 'hT' '"^^ ''^P ^^"r^ transmitting the QoS 

to the second WSTA ovS lej On!^ fh. OnV ^ f ' transmitting the QoS action frames 

time (i.e.. channel banZdth) Ws"! can cLlnl^^ ""I '^"^ ^'^'^'^^ transmission 

rnn-^fti o^c r '"w.am;, ine W55 1 As can communicate directly without having to transmit to the HC 257 

Sreai. ^ s::^:^;:^:::^^:^ r r-'- and™:f t^tfic 

in the IVILME and issued toThe ^mf nf!h ^ ^"^ *° *® '^'"'^^ °^ « communicating station or 

infomnln QoS^X trebodiL^^^^^ T^' ^^'^T ^"""'^^^ S -^*^ "t'^- 

QOS action frame may be a requeZrTresponsG ^ ""^ « 

unique in the course of carryinq out the trX «;trT«m .hhv . . " ^ ' ^"^ ^'^'"^ transaction number 
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TERS, and TIMEOUT, for example. If the MLME-ADDTS. REQUEST action primitive was issued by an HC, then the 
traffic specification specified in the traffic specification field 31 6 is the same as the traffic specification specified In the 
MLME-ADDTS.REQUEST, but it may be different if the MLME-ADDTS.REQUEST action primitive was issued by a 
WSTA. Reasons for changing the traffic specification are discussed below. Remaining fields In the stmcture: dialog 
5 token 314, traffic specification 316, and traffic classification 318 fields are as described previously. According to a 
preferred embodiment of the present invention, the MLME-ADDTS.CONFIRM 310 is generated by the MLME of the 
station whose SME issued the corresponding MLME-ADDTS.REQUEST 

[0042] Referring now to Figure 3c, a diagram illustrates the structure of a QoS action primitive used to Indicate an 
Initiation of adding (or modifying) a traffic stream by a specified peer MAC entity, MLME-ADDTS.INDICATION 320, 

10 according to a preferred embodiment of the present invention. This QoS action primitive is generated by the MLME of 
a station as a result of the receipt of an Initiation to add (or modify) a traffic stream at the MAC entity of that same 
station In the forni of an Add TS request action frame. The fields of this QoS action primitive are the same as those of 
the MLME-ADDTS. REQU EST action primitive. The fields in the structure Include dialog token 322, traffic specification 
324, and traffic classification 326 and are as described previously. 

15 [0043] Referring now to Figure 3d, a diagram illustrates the structure of a QoS action primitive used to respond to 
the initiation of a traffic stream addition (or modification) by a specified WSTA MAC entity, MLME-ADDTS. RESPONSE 
330, according to a preferred embodiment of the present Invention. A result code field 332 reports the result of the 
MLME-ADDTS.INDICATION specified with a dialog token field 334, with the possible result codes being: SUCCESS, 
INVALID PARAMETERS, and TIMEOUT, for example. This QoS action primitive is generated by the SME at the HC 

20 as a result of an MLME-ADDTS.INDICATION action primitive and approves or changes the addition (or modification) 
of a traffic stream as specified by the MAC entity of the WSTA. The remaining fields in the structure: dialog token 334, 
traffic specification 336, and traffic classification 338 are as described previously. If the MLME-ADDTS.INDICATION 
was generated at the HC, an ADD TS RESPONSE ACTION FRAME Is sent from the HC to the communicating station 
of the traffic stream that initiated the corresponding MLME-ADDTS.REQUEST. 

25 [0044] Referring now to Figure 3e, a diagram illustrates the structure of a QoS action primitive used to request the 
deletion of a traffic stream with a specified peer MAC entity or entities, MLME-DELTS. REQUEST 340, according to a 
preferred embodiment of the present invention. This QoS action primitive initiates a traffic stream deletion procedure, 
with a dialog token field 342 specifying a unique action primitive and frame transaction number used in the course of 
carrying out the deletion action. The traffic specification field 344 defines the traffic stream to be deleted. The 

30 MLME-DELTS. REQUEST 340 may be generated at the SME of either the source or destination station of the traffic 
stream, or at the SME of the HC. 

[0045] Referring now to Figure 3f, a diagram illustrates the structure of a QoS action primitive used to confimn the 
results of a traffic stream deletion attempt, MLME-DELTS.CONFIRM 350, according to a preferred embodiment of the 
present invention. A result code field 352 reports the result of the MLME-DELTS. REQU EST specified with a dialog 
35 token field 354, with the possible result codes being: SUCCESS, INVALID PARAMETERS, and TIMEOUT, for example. 
This QoS action primitive is generated by the MLME as a result of an MLME-DELTS.REQUEST action primitive. The 
remaining fields in the structure: dialog tokan 354 and traffic specification 356 are as described previously. The 
MLME-DELTS.CONFIRM 350 is generated by the MLME of the station whose SME issued the corresponding 
MLME-DELTS.REQUEST. 

40 [0046] Referring now to Figure 3g, a diagram illustrates the structure of a QoS action primitive used to Indicate the 
initiation of a QoS action primitive to delete a traffic stream by a peer MAC entity, MLME-DELTS.INDICATION 360, 
according to a preferred embodiment of the present invention. This QoS action primitive is generated by the MLME of 
a station as a result of the receipt of an initiation to delete a traffic stream at the MAC entity of that same station in the 
form of a DEL TS ACTION FRAME. The remaining fields in the structure: dialog token 362 and traffic specification 364 

45 are as described previously. 

[0047] Referring now to Figure 3h, a diagram Illustrates the structure of a QoS action primitive used to respond to 
an Inilialion of a traffic stream deletion by a WSTA MAC entity, MLME-DELTS. RESPONSE 370, according to a preferred 
embodiment of the present invention. A result code field 372 reports the result of the MLME-DELTS.INDICATION 
specified with a dialog token field 374, with the possible result codes being; SUCCESS, INVALID PARAMETERS, and 

so TIMEOUT, for example. This primitive is generated by the MLME at the HC as a result of an MLME-DELTS.INDICATION 
to initiate deletion of a traffic stream with a peer MAC entity or entities not located at the HC or the initiation station. 
Remaining fields in the structure: dialog token 374 and traffic specification 376 are as described previously. A DEL TS 
ACTION FRAME is sent from the HC to the aforementioned peer MAC entity or entities. 

[0048] QoS action frame bodies are actually carried inside QoS action primitives and extracted from, or inserted into, 
55 the action primitives while inside the SME and MLME, respectively, of the communicating stations or the HC. The action 
frames are used to transmit the QoS expectations, along with other information, between communicating stations or 
the HC via the PHY layer of the stations or the HC and over-the-air. QoS action frame bodies are extracted from the 
QoS action primitrves In the MAC sublayer of the station Issuing the primitive and inserted into QoS action frames for 
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code field 402. an action code f eld Jo^ZZ io^^^^^^^^ 'T^ ^^"''"^'"^ ' ^^^9°'V 

field 410. The category code field 402 idPnw^l f . ' ^ '^'^'"^ action^pecific 

404 specifies a spe'cir;^ ^nl::^^^^!^!:: ZT,:^ ' ''^'^ 

Seld'lSTn^^^t^rj:^;^^^^^^^^^ 

specific field 430. The action spS?kffte;us frel2^;^ ^ ^"ken field 428, and an action 

[0052] Referring now to pZe ^a ?b,e mus rZ Z °T '"^'"^ °' " corresponding action request, 
ferred embodiment of the p^sent^n^enSfn ZZ\T^" ''''^^'^ ^'^"^^'"S '° « P^^' 

action code fields 404 and 424 in the Qos ml«n!^^^^^^ T ""^ '^'"^ ""^P'^^"* '"^^ P°^='ble contents of the 

in Figures 4a and 4h, respeftt:, cTd^oTA^ t^RE^^^^ ^ "° '""^'^"^^ 

request frames (Figure 4a) while action code 1 (ADD TS RESPONSE^ K J l ^ "^^"'^ ^'^''^^ 
4b). Note that according to a preferred emhnriinlnt « ,k ^ •"^sponse frames (Figure 

forr^^f™ - 

fields and/or elementsfield 410 whi^^N C^^^ an exception given to the acion-specific fixed 

sub„^ 

^-rA^TiorpR^Erv x^ist rj:Sc STs ^ ^ r °^ - 

205 and communicated to fwirelL^^^ 

discussed previously, a QcS ac^on priS^^e conTain^^^ embodiment of the present invention. As 

istics and QoS parameters of a paLu.ar taTZ^t^ZZT^^^^^^^^ '-'"r 
provide for association of traffic characteristics and Oo9 na^™ . . communications traffic does not 

traffic Characteristics and QoSpaSmS of at^^^^ ^" °P«^^^'°" 

Of the communicating stations and the hybrid cooS^^^^^^^^^ '° -^^^ ^"'^ management entities 

acteristics and QoS paramJ^er^fo m^S^eam to ^ 

IVILIVIE-ADDTS.REQUEST (in the case ora^dina nr rrini? . 1 ' ^^^^^^^ ^ action primitive, 

the case of deleting a trafffrJiear^ )' ^ f Se ADC^^^'R^aSSlTo T° MLME-DELTS. REQUEST (in 
specifies the traffic characteristics and Oo^ nlrrr^^t 5^ . contains a QoS action frame body that 

stream. The ^.L^. E-ADD^ SeQUESt? 0 ^ ZZZr^Tl^'lT '.''^ ""^ ° ^^^^ 

MAC sublayer21 6 extracts the QoS aSon frame^odj f Z the O^s f ' '"''"'^ '^'^^^ " ^ sublayer 21 6. The 
ACTION FRAME 512 and passes the rc" oTrame n^ 

REQUEST ACTION FRAMEl^^to the SstI^Z '° '^''^ "'"^ ''"^ 'ayer 220 transmits the ADD TS 

[0058] The PHY layer of the WSTA 207 receives the ADD TS REQUEST ACTION FRAMp ri o ^ 
frame to its own MAC sublayer wherein the MAC «„m=w^ 7 ^ „ ACTION FRAME 51 2 and passes the action 

(ACK FRAME) 514. NoticeLuhe ACK^oW^^ 

TS REQUEST ACTION FRAME 512 and na^«n . 5 ^ ^^^P^"^^ ^"'y the receipt of the ADD 
FRAME512. upon receiptXelcKNO^E^^^^^^^^ 

primitive518from Its MLME backto its SME reoortn^tL nro^T ' ^! f °^ ^" MLME-ADDTS.CONFIRM 

610 Issued by that SME. At the WSTA 207 the Sac ^^l,!'^ ?^ "^^^^^^ MLME-ADDTS.REQUEST 

to the MLME Wherein the MLME cJ^afes a Qor^tn Z^^^^^ ''''''^^ REQUEST ACTION FRAME 

REQUEST ACTION FRAME5lLndSes?he Q^T^^^^ ^' ADD TS 
the contents Of theoos action pHm^lrand^^^^^^^^^^^^ 

same path is taken for modifying an existina traffic ^u^»r^Z.. 1 ? „ ^ ^^^'^ created. The 
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[0059] Referring now to Figure 5b, a diagram illustrates the path taken by QoS action prinnitives and action frames 
through the communicating stations and the hybrid coordinator when the QoS action is initiated by a wireless station 
according to a preferred embodiment of the present invention. The QoS signaling is initiated In the higher layer signaling 
unit of the WSTA 207. The higher layer signaling unit issues a QoS action signal for creating, modifying, or deleting a 

5 traffic stream, and provides the traffic characteristics and QoS parameters of the traffic stream to the SME, which in 
turn, creates a QoS action primitive, MLME-ADDTS.REQUEST (in the case of adding or modifying a traffic stream) 
560 (or MLME-DELTS.REQUEST (in the case of deleting a traffic stream)). The MLME-ADDTS.REQUEST 560 con- 
tains QoS action frame body that specif ies the traffic characteristics and QoS parameters provided by the higher layer 
signaling unit for the traffic stream. The MLME-ADDTS.REQUEST 560 is issued to the MLME, which relays it to the 

10 MAC sublayer of the WSTA 207. The MAC sublayer extracts the QoS action frame body from the QoS action primitive 
and creates an ADD TS REQUEST ACTION FRAME 562 and passes the action frame to the PHY layer. The PHY 
layer transmits the ADD TS REQUEST ACTION FRAME 562 to the HC 205. 

[0060] The PHY layer of the HC 205 receives the ADD TS REQUEST ACTION FRAME 562 and passes the action 
frame to its own MAC sublayer, wherein the MAC sublayer automatically generates an ACKNOWLEDGMENT FRAME 

15 (ACK FRAME) 564. Notice that the ACKNOWLEDGMENT FRAME 564 is in response to only the receipt of the ADD 
TS REQUEST ACTION FRAME 562 and is not an acknowledgment of the contents of the ADD TS REQUEST ACTION 
FRAME 562. At the HC 205, the MAC sublayer relays the received ADD TS REQUEST ACTION FRAME 562 to the 
MLME wherein the MLME creates a QoS action primitive, MLML-ADDTS. INDICATION 566, from the ADDTS. RE- 
QUEST frame 562 and issues the QoS action primitive to the SME. The SME of the HC 205 processes the contents 

20 of the QoS action primitive and creates another QoS action primitive, MLME-ADDTS. RESPONSE 568. The purpose 
of the MLME-ADDTS. RESPONSE 568 is to provide a response back to the WSTA 207. The response provides a set 
of traffic characteristics and QoS parameters that the HC 205 is able (or willing) to accommodate for the traffic stream. 
For example, the WSTA 207 may request a set of QoS parameters that the HC 205 does not have sufficient channel 
bandwidth to meet. Alternatively, the WSTA 207 may request more bandwidth than the HC 205 is willing to allocate to 

25 one traffic stream. Therefore, the response action primitive provides a set of traffic characteristics and QoS parameters 
that the HC 205 approves for the traffic stream. 

[0061] The MLME-ADDTS. RESPONSE 568 primitive is issued to the MLME and then relayed to the MAC sublayer 
of the HC 205, where the MAC sublayer strips the QoS action frame body, creates an ADD TS RESPONSE ACTION 
FRAME 570, and passes the action frame to the PHY layer 220. The PHY layer 220 of the HC 205 transmits the ADD 

30 TS RESPONSE ACTION FRAME to the PHY layer of the WSTA 207. Upon receipt of the action frame from the HC 
205, the PHY layer of the WSTA 207 passes the received action frame to the MAC sublayer. The MAC sublayer, in 
response to the received action frame, generates an acknowledgment frame 572 that is returned to the HC 206. The 
MAC sublayer relays the ADD TS RESPONSE ACTION FRAME 570 to the MLME, where a QoS action primitive, 
MLME-ADDTS.CONFIRM 574, is created from the ADD TS RESPONSE ACTION FRAME 570. The MLME-ADDTS. 

35 CONFI RM primitive 574 is then issued to the SM E of the WSTA 207. The SME of the WSTA 207 processes the contents 
of the QoS action primitive, and the traffic stream between the WSTA 207 and the HC 205 is created. Should the HC 
205 modify any of the QoS parameters requested by the WSTA 207, the SME at the WSTA 207 provides the changes 
to the higher layer signaling unit. The same path is taken for modifying an existing traffic stream by using the traffic 
stream identifier (TSID) forthat traffic stream in the QoS action primitives and frames. A similar path is taken for deleting 

40 an existing traffic stream. 

[0062] Referring now to Figures 6a-b, diagrams illustrate the structure of a traffic specification (TSpec) element for 
use in specifying the traffic characteristics and QoS parameters of a traffic stream according to a pretended embodiment 
of the present invention. 

[0063] Referring now to Figure 6a, a diagram illustrates a format of the traffic specification element for defining the 
^5 traffic characteristics and QoS parameters. The traffic characteristics and QoS parameters are placed In a traffic spec- 
ification element and communicated to the MAC sublayer of the hybrid coordinator (HC) and wireless statlon(s) (WSTA) 
that may be either the source or destination of the traffic stream. 

[0064] In addition to the traffic characteristics and QoS parameters, the traffic specification element includes the 
following fields, with their preferred sizes: a one-octet element ID field (601 ) identifying the traffic specification element, 

50 a one-octet length field (603) indicating the length in units of octets of the following fields in this traffic specification 
element, a six-octet source address field (605) of the traffic stream, a six-octet destination address field (607) of the 
traffic stream, a two-octet traffic stream identifier and association identifier (TAID) field (609) fomned as a concatenation 
of the traffic stream identifier (TSID) of the traffic stream and an association identifier (AID) of a wireless QoS station 
(WSTA) to identify the traffic stream in the context of the WSTA in a QoS basic service set (QBSS), and a one-octet 

55 traffic stream information (TS Info) field (611) providing additional infonnation about the traffic stream. Further infor- 
mation related to these fields can be found in the IEEE 802,11e/D2.0a draft standard. 

[0085] Referring now to Figure 6b, a diagram illustrates the structure of the TSInf o field 611 in greater detail according 
to a preferred embodiment of the present invention. The TSInfo field 611 is preferably an eight-bit field, partitioned into 
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M ackno^leagmen. policy ^<^^T.Xw,St,^'^,^^l""°, " »' fractional. A1«o- 

-«*,e pH0„„ ,0, use o„ da,a .a„„„ o, .^0°?^ r.^S'^lirpTo^^LTJ^r ^^^^ ' 

transmitted frameofthetrafficstreambeforrth^^^^^^^^ 
interval field (615) specifyingTm^imur^^^^^ 

Without the arrival or transfeT of «n M^<.n kIZ: „ " ! ""«t.lP^^'^^^t,'y e-ght millisecond units) that can elapse 

MAC at the HC. and an interarrival iniervaif.e W mi 7?,n^^^^^^ , ""^"'^ ^^'^^^^ by the 

the traffic stream which may be used bv fhe Hr «1 1 '^T^"'^ t "J'"""^' '"te^'al of MSDUs belonging to 

[0067] Additional traffiSaracteristS and QoS oL«"' ! ""^ '^'^ ""^""'^^ °^ t^^^'^ ^'^^--^ 

nominal MSDU size field (61 gTtecifl^na a n^^^ ''^"'^ specification element include: a 
rate field (621) soeclfvinn « ^7„rr'::r "-'""S'^g to the traffic stream, a minimum data 

traffic stream, a mean data rate fXess) 30001^1" iom nlf f '^""'"'^ ^'^^ '^^'^ °f t^^e 

second) for the data transfer of tl^^ time strSm ^mLimr h T^'t '^'^ (P^^'^^^^'V ki'oblts per 

in units (preferably in eight octet uniS o? MSDU. tl ? ^ "^"^ specifying a maximum data burst 

a maximum time I unte (preferatJvti llf^,r .^'"^ '° '""^ ''^'^'^ ^ ^^'^^ "ound field (627) specifying 

stream, and a jitter ^Z^ Z^^^^^^^^ ^" '"^^^ »° tSo traf?ic 

belonging to the traffic stream, ic Jrd Sg^L 'pref^ZTboS ""T"" " ''^ "^^^^^ 

Snt n"o1^^^^^^^^^ - -on frames have a traffic classification 

isr wit^hi^rrrs^srm^^^^^^^^^^^^ °' ^^--^'^^ ^vto 

iSngraT^frdl^orml^^^^^^^^^^^^ 

a classiflertype field (711). and a frame rsSteldmarThr T ^ ^^^^'^'^ priority field (709). 

this particular frame classification 7ete'^To oXe f^i r P"°'^ty "^Id 709 specifies a search orderfor 

located above the MAC service a Jet pJnt (SAP a^SoSjn (Sl?^ ' T '^'-^^f-^- ^^^le (not shown) 
the present invention, the frame classiftere are used in o^H.f o ! <°^?^\^°'-'^'"9 to a preferred embodiment of 
priority maintained in the classificarnSe un«^^^^^^^ ascending mteger values (unsigned) of the search 

classifiers In that table is exhauLTed " "'^'"''^'^ ""'^ ^ ''^^ '^'^^''''^^ °^ the set of frame 

Sed'^rdSr rhi'Z'itre:^^^^^^^ sTor^™''? '-''^ — « - « 

contents are as follows: 'nvent.on, a set of possible classifier types and the frame classifier field 713 



[0071] 



Classifier Type 


Frame Classifier Contents ' \ 


0 


Traffic stream identifier (TSID) 


1 


TCP UDP source and destination port 


2 


IEEE 802.2 LLC DSAP and SSAP addresses 


3 


IEEE 802.1 Q tag header. IEEE 802.1 D user priority, IEEE 802 1Q VLAN ID 


4 


IEEE 802.3 MAC header destination and source addresses and tvoe 


Other 


Resented • — 



(transmuted) between commXnlcat^g sta ;r(^ n^^^^^^^^^^^^ -tlon frames sent 

to a preferred embodiment of the present invention ' ^"'^ "^'^^^ ^^'^^^ according 

the SME Of the HC generates an MlXadd4 rSup^t L t "^^^ begins when 

The MAC strips the embedded ADD TS reques^ ac^^^^ FRAMP 7 '° "^^^ °' 802. 

primitive and transmits it to the MAC of the WSjf Io4 ^J^^rL?^ '""^ MLME-ADDTS. REQUEST action 

iviAu or the WSTA 804. The transmrssion between the MACs of the HC and the WSTA 
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is performed via the PHY layer of the HC, wireless transmission over-the-air, and the PHY layer of the WSTA. 
[0073] The MAC of the WSTA returns an ACK FRAME to the MAC of the HC to acknowledge the receipt of the ADD 
TS REQUEST ACTION FRAME 806. After receiving the ACK FRAME from the WSTA. the MAC of the HC generates 
an MLME-ADDTS.CONFIRM action primitive and issues It to the SM E of the HC 808. The MAC of the WSTA generates 
5 an MLME-ADDTS. INDICATION action primitive and issues it to the SME of the WSTA 810. 

[0074] Referring now to Figure 8b, a diagram illustrates an inactivity initiated deletion of an existing traffic stream 
according to a preferred embodiment of the present Invention. The MAC of an HC notices that a particular traffic stream 
has been idle for a time period that is greater than the inactivity interval specified in the traffic specification element for 
that traffic stream, and thus issues an MLME-DELTS.INDICATION action primitive to the SME of the HC 812. The SME 

10 generates an MLME-DELTS. RESPONSE action primitive in response to the MLME-DELTS.INDICATION and issues 
it to the MAC of the HC 814. The MAC of the HC also creates a DEL TS ACTION FRAME and transmits it to the MAC 
of the WSTA associated with the traffic stream 816. The MAC of the WSTA sends an ACK FRAME back to the HC in 
response to the receipt of the DEL TS ACTION FRAME 8 1 8. Finally, the MAC of the WSTA generates an MLME-DELTS. 
INDICATION action primitive and transfers It to the SME of the WSTA 820. 

15 [0075] Referring now to Figure 8c, a diagram illustrates a source WSTA initiated deletion of a traffic stream between 
a source WSTA (WSTA1) and a destination WSTA (WSTA2) according to a preferred embodiment of the present in- 
vention. The deletion begins with the SME of WSTA1 generating an MLME-DELTS. REQUEST action primitive and 
Issuing it to the MAC of WSTA1 822. The MAC of WSTA1 strips the DEL TS ACTION FRAME body that is embedded 
in the MLME-DELTS.REQUEST action primitive and transmits it to the MAC of the HC 824. The MAC of the HC returns 

20 an ACK frame to the MAC of the WSTA1 in response to the receipt of the DELTS ACTION FRAME 826. 

[0076] The MAC of WSTA1 generates an MLME-DELTS.CONFIRM action primitive and issues it to the SME of 
WSTA1 828. At the same time, the MAC of the HC generates an MLME-DELTS.INDICATION action primitive and 
transfers it to the SME of the HC 830. In response to the MLME-DELTS.INDICATION action primitive, the SME of the 
HC generates an MLME-DELTS. RESPONSE action primitive and issues it to the MAC of the HC 832. The MAC of the 

25 HC strips the DEL TS ACTION FRAME body embedded In the MLME-DELTS. RESPONSE action primitive and trans- 
mits It to the MAC of WSTA2 834. The MAC of WSTA2 returns an ACK FRAME to the MAC of the HC in response to 
the receipt of the DELTS ACTION FRAME 836. The MAC of WSTA2 generates an MLME-DELTS.INDICATION action 
primitive and issues it to the SME of WSTA2 838. 

[0077] Referring now to Figure 9, a diagram illustrates an example of the use of traffic streams according to a preferred 
30 embodiment of the present Invention. As displayed in Figure 9, there are two originators within a local QBSS 900 
controlled by a single HC 910. with each of the two originators on separate WSTAs 920 and 930 and the destination 
parties located outside of the QBSS. Let a first originator and destination pair be involved in a voice call 925 and a 
second originator and destination pair be involved in an Internet web browsing session 935. Since both sessions are 
bi-directional in nature, a total of four uni-directional traffic streams are required. 
35 [0078] Assuming that the voice call 925 Is equally sampled at a rate of 64 kbps In each direction, packetized every 
20 ms and transmitted over UDP/IP. Then the two voice traffic streams may be combined into a bi-directional traffic 
stream specified by a single TSPEC. This TSPEC may then specify an TID subfield of 8 in the TAID field, an inactivity 
interval of 5 minutes, an interarrival interval of 20 ms, a nominal MSDU size of 188 bytes, a minimum data rate of 75.2 
kbps, a delay bound of 50 ms, and a jitter bound of 40 ms, along with an isochronous traffic type and a true bi-directional 
40 value. 

[0079] On the other hand, assume a 5 percent duty cycle for the web browsing session 935, meaning that the user 
is actively sending and receiving traffic 5 percent of the time (on average). While the user is active, the outbound traffic 
leaves at 144 kbps over TCP/IP with an average packet size of 360 bytes, while inbound traffic arrives at 1 .544 mbps 
over TCP/IP with an average packet size of 772 bytes. Due to this traffic asymmetry, two unl-directional traffic streams 

45 are needed. The TSPEC for the outbound traffic stream may specify a TID subfield of 1 3 in the TAID field, an inactivity 
interval of 20 minutes, an interarrival interval of 20 ms, a nominal MSDU size of 360 bytes, a minimum data rate of 1 44 
kbps (measured over active periods), a mean data rate of 14.4 kbps (measured over both active and inactive periods), 
and a delay bound of 500 ms, as well as an asynchronous traffic type and a false bi-directional value. The TSPEC for 
the inbound traffic stream may specify a TID subfield of 13 in the TAID field, an inactivity interval of 20 minutes, an 

so interarrival interval of 4 ms, a nominal MSDU size of 772 bytes, a minimum data rate of 1 .544 mbps (measured over 
active periods), a mean data rate of 154.4 kbps (measured over both active and inactive periods), and a delay bound 
of 1 second, as well as an asynchronous traffic type and a false bi-directional value, 

[0080] Based on the TSPEC and available bandwidth, the HC 910 makes an admission control decision on the voice 
call and the web browsing session, I.e., the HC 910 decides if either or both or neither of the traffic streams are to be 
55 created. If both are allowed, both TSPEC parameters are provided to the MAC entities at the HC 91 0 and the source/ 
destination WSTAs 920 and 930 within the QBSS 900, using the earlier discussed signaling procedure. The HC 910 
schedules quasi-periodic transmission times for both directions of the voice traffic stream 925. The HC 91 0 schedules 
the transmission times for the voice traffic stream 925 due to the low latency requirements of a voice connection. The 
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10 



15 



20 



25 



to meet both delay and jitter requ rei^^E^^.t^ ^^^^^^ ''"'^^ '^"""^ ^"^ ''°""^) order 

MSDU Of 188 bytes. The HC 91 0 wrdeete the Se^^^^^^^^ J at least usable for, ransferring an 

direction are found over an Interval of 5 minutes "° ^"'^^^ "^SDUs in each 

910 to the involved WSTA 930 of the web traff c Xc^cn rti^it r . ? ^ ^"^^'^'^ for transmission from the HC 

buffered for transmission from the invotd ws^ So ^ TT'u^^ ^"'^ '"^'^^^^ ^^DUs 

report as send from that WSTA 930 wTen there arfMSnn« tr ?f '° '^l*"^ '"'^"'^^'y ^''^^ '^"^^'^ traffic 

arrange transmission times within 1 second of the' alTl^ ''^ ^Sf'A ^^0, the HC will 

at least an MSDU of 772 bytes The ^910 must scheS ir IT being usable for transferring 
of 144 kbps for the WSTA H J transfer anS rm nllm H^ 

respective active periods. However the HC 91 O^raZTuT. '^^^^ "^''"^ "^"^^^^ t^^e 

Of 14.4 kpbs and 154.4 kbps on overaH averaoes S orovi^^H h ''"^^ *° "^^^^ '^t-s 

~ingtra.cstream%3Sforeach-^^^^^^^ 

^E^iddiX'trrcTr^ 

Referto the IEEE 802.11 and IEEE 802 i?e/D2 Oa technical stanrrf '''°"^'^'' "^'^^ "^^^^"^ transmission. 
FEC bte. MAC and PLCP headers, and Prcp prelm^r n m^^^^^ ^ '""''^ ''^'^"^^ explanation of privacy and 
;u..rconsidertheinte.ramespac^ 

as well as other embodiments of IVZlnt^r^-u ^Z^r^^^. combinations of the illustrative embodiments. 
..scription.lt is therefore intended thatthr-el^^^^^^^^^^ 



30 Claims 



45 



SO 



55 



:S (ImeTo' th?StSl'°"' ' '^^^^ ^'^"^""^ °^ to a station management 

trOolVcitrflrbrd; ''^ °^ ^^^^-^ ^-^^ -non p^mitlve comprising a 
iJarm^rgTiSrs'S^^^^^^^ 

receiving an acknowledgment fr^rthe ilcond station """^ *° " ^^'^""'^ 

2. The method of claim 1 , wherein the first station is a source station of the trafffc stream. 

3. The method of claim 1 . wherein the first station is a destination station of the traffic stream. 

4. The method of any preceding claim, wherein the flr.t station is a station containing a hybrid coordinator. 

5. A method for communicating w.h parameterized QoS expectations in a communications network comprising: 

creating a set of parameterized QoS expectations- 
transmitting the set to a destination station- and 

™--*°<'«"*=<um.-oo.pr,s,„g,he««.o,ae,,,,„8,.eco.™„»=a,,.„s,««„« 
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completes. 



7. The method of claim 6. wherein there is a station at each end of the communications link, and the deleting step 



generating a delete request at one station in the communications link; 
transmitting the delete request to the other station in the communications link; and 
deleting the communications link upon receipt of an acknowledgment from the other station. 

10 8. The method of claim 5, claim 6 or claim 7, wherein the source station comprises: a higher layer signaling unit, a 
station management entity (SME), a MAC layer management entity (MLME), and a PHY layer management entity 
(PLME), and the creating step comprising: 

receiving the set of parameterized QoS expectations from the higher layer signaling unit at the SME; 
'5 generating a QoS action primitive with the parameterized QoS expectations provided in the set of parameter- 

ized QoS expectations; and 
transferring the QoS action primitive to the MLME. 

9. The method of claim 8, wherein the creating step further comprises: 

20 

extracting a QoS action frame from the QoS action primitive; and 
providing the QoS action frame to a PHY layer of the source station. 

10. The method of claim 5, wherein there are a plurality of messages transmitted in the communications network, and 
25 each message can be transmitted using a different set of parameterized QoS expectations. 
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